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(54) Abstract Title 

Communications protocol for connecting a mobile terminal to a node using internet protocol 



(57) A communications protocol for providing a connection-oriented interconnection yia an internet protocol 
communications system (for example, via the Internet) between a first mobile terminal and a node (for 
example a fixed or mobile terminal or a server), in which the first mobile terminal and the node form part of an 
internet session; in which the first mobile terminal is initially connected to the node via a first mobile controller 
(MC) in which the protocol comprises means for providing to the first MC an internet address relating to the 
node and a record number identifying the internet session. The protocol also provides for maintaining the 
session as the interconnection between the first mobile terminal and the node is redirected from via the first 
MC to via a second MC (Fig 3A). 



Fig.3. 



MESSAGE SEQUENCE 
1. OPEN 
2a SERVICE_ACK 
2b. SERVICE_REQUEST 
3. 0PEN_SERV1CE 



FIXED TERMINAL OPENS A SESSION WTTH MOBILE TERMINAL 
(OPEN _D0NE_ and REQUEST_D0NE messages not shown) 



SORTER 

SERVICE_REQUEST? T 



to Sorter 



SERVICE_REQUEST| 
to Sorter i 



J 1_ 



SERVICE.REQUEST 
toM.LS. 
ROUTER V 




, SERVICE_REQUEST 
TO MOBILE TERMINAL 



Mobile 
Terminal 



USER 


>0PEN> 


ROUTER 


0PEN_SERVICE 


ROUTER 


0PEN.SERVICE 


ROUTER 




BSC 


n 


<SERVICE_ACK< 







0PEN_SERVICE 0PEN_SERVICE 



path of SERVICEJEQUEST message 

* virtual-message path and direction of establishment 



O 

CD 

ro 
CO 

CO 
00 



1/10 




2/10 



LU § 

CO o 

-Ll -§ 

QJ = 

Q- CO 

CO CD 

<C c? 

DC co 

O CD 

U- E 



CM gS 
OS,.' 

LL CO LU 

£2B 



CO 



CO 



LU — 



CD 



I 



h- a. 

O 



LU 
O 



CO 



a 

LU 

CO 



^ a o 

OLU> 

<COC£ 

I LU 
UJ LU Jo 

O O | 
wm 3^ ^> 

lu oc ac lu 

< Q.LUUJQ. 
^ O CO CO o 

!^ . c6j6 . 

2 t- CM CM CO 



r 

JL 



CO 
LU 

sg 

DC C- 

I ° 
ujco 

> 

DC 
LU 
CO 



O 
DC 

T" 



S g 4 

QC C- 



"l CD I 

CO I 



I 









QC 


LU 

CO 


oc 


LU 




LU 


h- 




H- 


or 






o 




O 


CO 




DC 




CO 





QC 
LU 
CO 



i LU 

4 v 



o 

DC 



O 



LU 
I— 

o 

DC 



O 

QC 
LU ^ 

CO } 

I 

LU 

a. 
o 



o *— 

LU «S 

OS 

LU 

CO 



CO 
UJ 

a »- 

LU 52 
Ljj ! CO 

DC 
LU 

CO 





V 








o 


A 






3 


LU . 

a. i 




o 




A 


QC 
LU 




CO 




V 



DC 
LU 

CO 



CD 

E 

CO 



& 

CO 
CD 

CO c— 

£ .2 

E £ 



CO 



a * 

* 

LU °- 

O CD 

CO 

DC co 
LU CO 
CO Cg 

° * 
■a e 



3/10 



CO 



CO 



CO 

-s 

cc c 

UJ CO 
U_ CD 

co o> 

22 CD 
co 

S co 

CC CD 

»- E 

^2 CO 

■ £3 



cd 



< 

CM 



LL co 



CO 



a 

LU 

cc 



o 
a 



a. 





oc 




LU 
> 


LU 




z 


SE 



CO 



CO 



o 







OLD 


ERVE 




CO 



CO 



* 



DC 
LU 
LU 

CO 

<c 
cc t 



CO 

cc 



o 
cc 



o a 



lu cc co 

a cc< 

LU LU OC 

CO LL. h— 

^ zz 

< OCQ- 
LU 

S ^ cvi 




CD 

as 
E 



a 

LU 

5 

LU 
LL. 
CO 



O 

i 



t 



CC 
CD 



CO 



O 
"5 

£ 
cd 

i 

CD 

CO 
CO 
CD 

E 

■ 

ca 



Cd 

o. 

CD 

cd 

CO 
CO 
CD 

E 

I 

cd 



2 
o 



4/10 



CO 



4 



2 o 

LU C 

5 £ 
o s> 

« CO 
— CO 
P- CD 

t E 



is 

* co Q , 
:— co eg 

ssS 

°I 

«! . 

z uj 

o «J-I 
uj Q- 

X o 



CO 



I — < 

CO 2 
SI 



O 
CO 
CD 




o 

DC 
LU 



Q. 
O 



O 

DC 
UJ 
CO 

I 



a. 
o 



CO 



o. 
o 



CO 





CO 




oc 




DC 


LU 




UJ 


1— 




h- 


OC 






O 




O 


CO 




DC 









St 



= 3 UJ 

^ UUJ> 

a <c °c.cr 

CO UJ LU Jo 

UJ 2 > > 2 

S5 UJ DC DC LU 

^ O CO CO o 

S i— CNJ CM CO 



S jg 

tu'co 
o o 



CO 



CO 



a »— 
uj « 

uj Ico 
o o 



co 



O 
oc 



LU 

o 

A 



V 

o 

UJ 

o 



CO 

V 



DC 
LU 

CO 



CD 

s £ 
« -s 

E cd 



CO 



a 

LU 
DC 



I 



O CD 
CO <| 

f i 



4 



5/10 



LU CC 



CO 




6/10 



CO 



CO 
CD 

CO 
CD 

E 

LU 

CO 

o 



CD , 

CO g. 

■ 



C3 



o 
o 



CD 
O) 

CO — I co 

uj <; 3> 
2qc E 

LU to 



r I 



a 

UJ 

co 

LU 

CD 

s§ 

CO 



L 



LU CD LU 

o < o £ 

-JX-J CO 

o o o cl 



i— CM CO 



22 co ^ 

LU O 3>4= 

Erg. 
Oh- £ cd 

Z 2 CO co 
O QC o E 



cd cO co 

t— CM CO 




CO 
CL 

CD 

s> 

CO 
CO 
CD 

E 
i 

CO 



CD 



i 

CD 

% 

CO 
CO 
CD 

E 

cd 



© 



7/10 



LU 
X 



o 

CO 
CO 
UJ 
CO 

<£ 

CO 



o 



QC 
LU 



CO 
O 







§ o 

ID LU 

co yd o o 
OC <r q 

cgooo 
2 1-^ cvi co 



a> 



8/10 



CO 



a! 



as 



1 



CD 



co 



10 
ci) 



^ E 



o z 
cog 

LU . I 



CO 



CO 

is 

o-o 



j« o 

S3 

LLj LU 
CQ O 

o ^ 




A 

a 

UJ 

DC 

I 



oS 
LU 
O 

A 



O 
CO 
CO 











CO 




CC 


GC 


LU 




LU 


1— 




1— 


CC 






o 




o 


; co 




CC 




1— 





CO 



Eg 

CC £ 

©a 

LU 

O 

Eo 



CO 
LU 



lb'* 

LU 
O 

?0 



CO 



ZD CC C-J |LU 

a u- <.il o 
uj "J Ilu> 

CO 0C LU CE CO 

g <g I 

CD LU DC O LU 
< Q- LU B> O- 
O CO CO o 



V 
LL. 
LU 
CC 
oS 
LU 
O 
> 

LU 
O. 

o 

V 

V _ 



LU 
O 



O 

V 



_co 
*a3 

O 
co 

CD 



■a lu 
CC z 

o£ 
ego 



LU 

CC 
p3 
LU 
O 
> 
CO 



o 

V 



V 

s> LU 

UJ o 

CC z 
LU uJ 

co S. 

Vo 

V 



o 
co 

CD 



A 

a 



cc 

o9 



o 

A 



CM CO 



V 

o 



CO 

V 



.92 
o 



cd 



CD 
CD 



55 

LU 

a 

LU 



oS — 



o 



4 



a> 



cd 



JO C 
O £ 



CO 

I 

CO 

o 

c: 
"S 

■o 

CO 

a3 



cd 

* I 

JZ. 3 



9/10 



o 

> c" 
cc 5 

^ -s 

o = 
£ $ 

CO O) 

< is 

LO 8§ 

. LU j 

■ — ■ III 

Li- £B 

LU LU 



LU O 



=± a. 

OQ O 

O * — * 



o 
cc 
— r- 



CO 



,i 1 cd 
oc o 

LU 

o 



ar 

LU 
CO 



CO 



CD i 



LU 

t 1 • 





CO 




CC 




cc 


LU 




LU 


H— 




h- 


CC 






O 




O 


CO 


h- 


CC 




CO I 



a . 

I o 

OS 

LU 
O 

CO 



CO 
LU 



I o 
LU CO 

LU 

o 



CO 



CO 
LU 

LU ZD LL. 

o _ ay 
z a ^ lu oc 

LU LU ^ OC 

d tro i lu 

O LL. <, LU CD 



CO 



_ IL. ^ 



LU QC O LU 
„7? CL. LU > Q- 

o CO CO o 
. cc -ci 

S i— CVJ CM CO 



O 
QC 



LU u- 

o S£ 

CO CD 
I CO 

LU 

o- 5 
o ^ 



oc 

oS 



CO 



o 
oc 



o 
oc 



CD O 
-O LU 
-O DC 
<C LL. 

DC Z 
LU 

a 



oc 



CO. 



a. 
o 

V 



V 

V U- 
oo 

J i LU O 
g35 



o 

CO 
GO 



I 

LU m 

CO 3. 
V o 

_ v 



A 

a 



oc 
z 

LU 
Q- 

o 

A 



V 
O 

2 

o 



CO 

V 



CD 

CD E 

c? 1 

CO -= 

co -Q 

o ^ 

E to 

. CD 



CO 



o 

c 
o 



a .2 
i £ 

LL, -5 



"53 
cd 



Si 

LU 

o 

£o _ 

JSC =3 
Q. > 

I 



4 



CD 



ca 



10/10 




cd 






NEW 


CO -Q 


ermi 


< 




i — 



i L 



CO 
LL 



I 



O 

1 



CO 



o 

CD 

1 



LU 



SO 
LU CO 
Z CO 



o0 



cn ] v k 

o T 



CL. 
O 



CC 
CC 



I 

CO 

o 



CO 
LU 



Q O 
-J CO 
O CO 



I 2 I's 



CC 
o3 
CC 
LU 

o 



t 



CC 
LU 
I — 

o 



CO 



o tu 

LU CC 

i_U CC 08 

o I cc 

£u 

S =g 
LU I2 

8 s <=> 

LU 

2 1— CM 




CL. 

o 



;rver 


BSC | 


LU 

CO 


0 



03 



CO 



cd 

CD ^> 

cd o 

CO _ 

£ .1 



CO 



o 
t5 



ll> a 

LU a " 

OC CD 

rr" Cw 

HF co 

H- co 

I— . « 

1 1 

■8 I 



cd 



♦ 



cd 

CL 
CD 

g 5 

CO 
CO 
CD 

E 
1 

cd 



2 
o 



2367978 



1 P/61151.GBA 
COMMUNICATIONS SYSTEM 

The present invention relates to a communications system and a communications protocol 
therefor, and more particularly to such a system and a protocol in which mobile terminals can be 
5 accommodated in a connection-oriented mode in an internet protocol communications system. 

La. 

The "connection-oriented mode" is described in related published British patent application "A 
10 Communications Network", publication number GB 2313271, assigned to Marconi 
Communications Limited which is incorporated herein by reference. To assist the reader, a brief 
outline of the connection-oriented mode is provided next. 

2.a. 

15 The connection-oriented mode enables Internet sessions to be conducted in a connection-oriented 
manner along with conventional connectionless sessions. This will require Internet sessions to 
use virtual message-paths made up of a series of virtual channels, one for every link of the path. 
Once a virtual message-path has been established at the start of a session, messages may be 
passed in either direction using only a number which identifies the virtual message-path on each 

20 link of the path (by means of a virtual channel number ( VCN)) so avoiding the need to add an 
address to each message. 

2.b. 

By way of introduction, the connection-oriented Internet session known from the related patent 
25 application will be described with reference to Figure 1. 
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The connection-oriented mode works by the establishment of a virtual message-path between two 
Internet terminals and enables those terminals to engage in dialogue as though they were directly 
interconnected, (i.e. the network is told that all messages from terminal A, activity x must be 
5 passed to terminal B, activity y, and vice-versa.). The conventional Internet is one example of an 
internet protocol communications system but is not "connection-oriented" (i.e. it is not told of 
a relationship between terminal A and terminal B) and requires that each message-packet from 
either terminal is individually addressed to the other terminal. 

10 2.b. 

To establish a "connection-oriented" session, a user opens a virtual channel to its local Internet 
router (Internet access point) and sends an OPEN message containing the internet address of the 
distant, destination terminal and identifying the protocols available for the transport layer activity 
which will use the virtual message path. A suitable format for each message type is given at the 
15 end of the description. In the following, the router providing the Internet access point to the user 
initiating a session is referred to as the "source router". Similarly, the router providing the 
Internet access point to the destination terminal is referred to in the following as the "destination 
router". 

20 An internet session is taken to include all activity on the virtual message path set up as a result 
of the initial OPEN message together with all activity on any further virtual message paths added 
to the session or to which an existing virtual message path forming part of the session is 
transferred. 
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In the conventional Internet a user sends the internet name of the desired destination terminal 

via its local router to the Internet domain name server (DNS) which returns the appropriate 

address to the user. The user is then able to use the destination internet address to access the 

desired destination. The conventional internet address comprises two parts: the network identity 

5 (NetID) identifies the network in which the destination terminal is located whilst the user identity 

(UserlD) uniquely identifies the desired destination terminal within the identified network. 

When the destination terminal is not a "special-service" (see below) the source router identifies 
the route towards the destination, allocates a virtual channel number (e.g. VCNx in Figure 1) on 
10 the link to the next router and forwards the OPEN message. The process is repeated until a 
virtual message path consisting of the successive virtual channels (VC) is established from the 
source to the distant destination terminal. The distant destination terminal returns an 
OPEN-DONE message stating the chosen protocol, link capacity and switching priority required. 
The transport layer activity now commences. 

15 

2.c. 

Each router records the path in its switching table 

e.g. Link A channel M switches to Link B channel N 
Link B channel N switches to link A channel M. 
20 Messages arriving at the router from link A labeled "M" will be re-labeled "N" and put into link 
B output buffer - and vice-versa. The switching table at the source router contains the 
identification of the link to the user terminal and an arbitrary reference number allocated by the 
user for uniquely identifying the present session. The switching table at the destination router 
contains the identification of the link to the destination terminal and an arbitrary reference 
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number allocated by the destination router for uniquely identifying the present session to the 

destination terminal. 



Control messages (OPEN,CLOSE etc.) use a control message channel, the control message 
5 header indicating the channel number to which the message applies; the header will be modified 
as control messages are passed from link to link. 

3.a. 

A special-service session will now be described with reference to Figure 2. 
10 A special-service session is one that starts with a user requesting connection to a service provided 
by a server (i.e. on a "destination" terminal) - but where the service is actually delivered and 
controlled by the server (i.e. the "destination") establishing a connection to the user (i.e. the 
"source") by means of an OPEN-SERVICE message from the destination end. 

15 3.b., 3.c. 

In order for a user to access a special service via the connection-oriented mode, the user obtains 
the internet address of the destination as before, however the Net ID no longer identifies a 
specific network but merely identifies that a special service is required. This is transparent to the 
user who uses the Internet address provided by the DNS in the normal manner. 

20 

3.d. 

The source router is set up to recognise that the user's OPEN message specifies a destination 
address that is a special-service, and to react by returning a SERVICE_ACK message to the user 
and sending a SERVICE JREQUEST message to a sorter (see below). The source router also 
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recognises that the charge-record, if any, will be prepared at the distant destination end. 



The SERVICE_ACK message tells the user that the initiative to open and close the transport 
layer activity will be at the distant, destination end, enabling the server to close the activity before 
5 transferring the user to another server, if required. 

The SERVICE JREQUEST message repeats the destination address and available protocols from 
the OPEN message. It also contains the user's Internet-name and the source router's own Internet 
address and its session-record number (see below). 

10 

With the connection-oriented service, a router needs to keep a record of each active session 
handled by it. When the virtual message path is closed, the relevant session record is updated. 
The session record only relates to that router's part of the session and enables the router to clear 
the relevant entries in its switching table, release the virtual channel numbers associated with that 
15 session and to release the reserved capacity on the links. The session-record may also be used for 
user accounting, inter-provider accounting, traffic recording and a variety of internal 
administrative purposes. 

As described in the related Application the sorter is a message re-addressing service attached to 
20 any convenient router and having an internet address similar to any other terminal on that router. 
By updating the sorters, services can be introduced, relocated or terminated. 

The sorter uses the "distant-host-address" destination address field in the SERVICE_REQUEST 
message to identify the true Internet address of the desired server. The address of the sorter in the 
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SERVICELREQUEST message is amended to the true internet address of the desired destination. 

Hence the sorter re-addresses the SERVICELREQUEST message to the required server. 

In forwarding the message via the sorter to the server a message-path is created for the return of 
5 a REQUESTJDONE or FAILURE message from the server to the originating router. 

3>e* T 3.f. 

Being aware of the user's identity enables the server to offer only the services considered 
appropriate for that user and so controls unauthorised access to services. 

The server uses an OPEN_SERVICE message to open a virtual message path to the source 
router, i.e. to the router address given in the SERVICE_REQUEST message. The 
OPEN.SERVICE message contains the session -record number copied from the 
SERVICE_REQUEST message received from the sorter and the user's internet name for 
verification by the source router. The message also indicates the chosen protocol and the capacity 
and message switching priority required for the session but the information is not used until 
transferred to OPEN_DONE messages. If the Internet name check fails, the BSC will return a 
FAILURE message instead of an OPEN_DONE message. 

20 3.g. 

The OPEN.SERVICE message is treated as a normal OPEN message by all routers except the 
source router. When the OPEN.SERVICE message is received from the distant destination end, 
the source router uses the session record number to identify the original virtual channel, 
established by the user to the source router by means of the original OPEN message. The source 



10 



15 
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router extends the virtual message-path from the destination to the user via the original virtual 

channel. This action is referred to as "picking-up" the virtual message path. The same action is 

required when a virtual message-path is changed in response to an OPEN TRANSFER or 

OPEN_MOB _TR ANSFER message (see below). 

5 

3.h., 3.i. 

A server may pass the relevant contents of a SERVICE-REQUEST message to another server 
in a TRANSFER_REQUEST or ADD_REQUEST message enabling the responsibility for 
service delivery to be transferred to another server or supplementing service delivery by 

10 introducing an additional server (see Figure 2A). The user is not involved in the transfer process, 
does not acquire the address of the additional server and so cannot bypass the first server on 
subsequent occasions. Also, service is delivered by the new or additional server directly to the 
user and details of the service delivered are not revealed to any other server involved in service 
delivery. For example, the first special-service server might be an insurance broker and the 

1 5 additional servers might be access points of relevant insurance companies. Alternatively, the first 
server might be the front-office of a multi-national business corporation leading to additional 
servers located in all the component parts of the business, and leading in turn to their sub- 
contractors and sub-sub contractors. 

20 3.j. 

A server transfers a user to another server by closing the transport layer activity and sending a 
TRANSFER_REQUEST message to the other server. The TRANSFER_REQUEST message 
contains the same information as the original SERVICE_REQUEST message, but indicates that 
the existing virtual message-path must be diverted. The message will usually be addressed 
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directly to the other server, but may be addressed via a Sorter as before, in which case the 

"Distant_host_address" field must be updated, as described in the related Application. 

The TRANSFER JfcEQUEST message may include information obtained during the earlier part 
5 of the session and may indicate which party is expected to pay for the transferred service. All 
such information is of no consequence to the Internet. The TRANSFERJREQUEST message 
will be forwarded to the new server and a message-path created for the return of a 
REQUESTJDONE or FAILURE message from the new server to the server initiating the 
transfer. 

10 

3.k. 

The new server uses an OPEN_TRANSFER message to create a virtual message-path to the 
source router. The message is similar to an OPENJ5ERVICE message: it includes the source 
router's session -record number and the user's internet name from the TRANSFER JREQUEST 
15 message. It also indicates the protocol chosen by the new server for use over the new part of the 
virtual message path including the new capacity and priority requirements, but this information 
is not used until transferred to OPENJDONE messages. 

3.1. 

20 The OPEN_TRANSFER message is treated as an ordinary OPEN message by all Routers except 
the source Router which uses the session -record number to identify the session and pick-up the 
message-path to the user. It also returns OPENJDONE messages to the new server and to the 
user containing the protocol, capacity and priority requirements indicated in the 
OPEN-TRANSFER message. The message title informs the source router that its session -record 
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and switching table contain entries relating to the previous message path. These entries must be 

updated and a CLOSEJREQUEST message must be sent to the old server on the previous 
message-path. 

5 3.m. 

Upon receiving the OPENJDONE message the new server will return REQUEST JDONE to the 
old server on the message path created by the TRANSFER_REQUEST. Upon receiving the 
REQUESTDONE message the old server will close the TRANSFER JREQUEST message path 
and upon receiving the CLOSEJREQUEST message from the source router the old server will 
10 close the previous message path. 

3.n., 3.o. 

A server may add another server by sending an ADDJREQUEST message to a new server 
containing the same information that would be contained in a TRANSFER JREQUEST message. 

15 The new server will establish a new virtual message-path to the user with an OPENLADD 
message containing the same information that would be contained in an OPENJTRANSFER 
message. The source router will return an OPENJDONE message to the new server which will 
send REQUEST JDONE to the server that initiated the addition. As described in the related 
application (see Part 1 "Creating a Virtual Message Path", in the section headed "The host/router 

20 link") sub-session numbers may be allocated to cope with the situation where a number of servers 
are in communication as part of the same session with a user over the same virtual channel. The 
source router will hence allocate a sub-session number for the new virtual message path and 
include it in the header of an ADDJ50NE message to the user. The ADD JDONE message also 
contains similar information to that contained in the OPENJDONE message. The sub-session 
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number is to identify the traffic flow over the new virtual message path to allow the user to 

distinguish between traffic sent or received via different virtual message paths. 
3.p. 

5 Upon receiving the ADDJDONE message, the user terminal will open a new activity as required 
to handle traffic to/from the new server. However, the connection orientated mode of the prior 
art does support the needs of mobile terminals. 

The present invention provides a communications protocol for providing a connection-oriented 
10 interconnection via an internet protocol communications system between a first mobile terminal 
and a node, in which the first mobile terminal and the node form part of an internet session; in 
which the first mobile terminal is initially connected to the node via a first mobile controller 
(MC) in which the protocol comprises means for providing to the first MC an internet address 
relating to the node and a record number identifying the internet session. 

15 

According to a preferred embodiment, the present invention includes the step of maintaining the 
session as the interconnection between the first mobile terminal and the node is redirected from 
via the first MC to via a second MC. 

20 Preferred embodiments of the present invention will now be described by way of example with 
reference to the drawings in which: 

Figures 1 and 2 illustrate operation of a protocol according to the prior art; 
Figures 3 to 6 illustrate operation of a protocol according to the present invention. 
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4 SESSIONS TERMINATED BV MORTT E TERMINALS 

Sessions terminated by mobile terminals according to the present invention will now be described 
with reference to Figure 3. 

5 

4.a. 

A mobile network consists of a network of aerial towers so arranged that a mobile terminal is 
always within range of at least one tower. Indeed, other than at the very extremities of the 
network a terminal is constantly within range of several towers. 

10 

4.b. 

All on-line (switched-on) mobile terminals, whether in use or dormant, are constantly monitoring 
and being monitored by all in-range towers. A inter-active process enables the towers and 
terminals to identify the tower currently most appropriate for each terminal. The tower so 
15 identified is considered to be the terminal's current location. The situation is constantly updated 
as terminals move from place to place. 

4x. 

The current location and identity of each on-line mobile terminal is reported to a network 
20 location register (e.g. located at the mobile network HQ) which must be consulted when traffic 
is to be directed to a mobile terminal. 

4.d. 

Several adjacent aerial towers are controlled by a single Base Station Controller (BSC) which is 
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the access point for those towers to and from the greater network and enables access to the 

telephone network and Internet. 

4.e. 

The network must accommodate an orderly "handover" when a mobile terminal moves from one 
5 aerial tower to another in mid-session. The move may include moving from one BSC area to 
another. 

4. f. 

According to the present invention each BSC has access to an internet router and is allocated an 
10 internet address but the mobile network is not an integral part of the Internet and may have access 
to other means of communication (e.g. the public switched telephone network). 

5. a. 

Referring to Figure 3, according to a preferred embodiment of the present invention, the network 
15 identity (NetID) of a mobile terminal will be a special-service NetlD. When a user requests 
access to a mobile terminal, the user's source router will send a SERVICE_ACK message to the 
user and a SERVICE_REQUEST message to a sorter. The router will also identify that the 
charge-record (if any) will be produced at the distant end. 

20 The sorter re-addresses the SERVICE JREQUEST message to the appropriate Mobile Location 
Service (MLS) which holds the current location of the mobile terminal and the identity of each 
mobile terminal's currently active BSC. The MLS re-addresses the SERVICEJREQUEST 
message to the mobile terminal's currently active BSC, which sends it to the mobile terminal. 
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5.b. 

The SERVICE_ACK message informs the user that the distant destination end is a 
special-service or a mobile terminal. The initiative to open and close the transport layer activity 
will belong to the distant destination end. 

5 

5.c. 

Upon receiving the SERVICE__REQUEST message the mobile terminal uses the source router 
address and session -record number obtained from the SERVICEJREQUEST message in an 
OPEN__SERVICE message to open a virtual message-path through the Internet to the source 
10 router and to pick-up the virtual message-path to the user. The BSC stores the source router 
address and session -record number from the OPEN_SERVICE message in its own session - 
record for use if the mobile terminal migrates to another BSC during the session. 



5.d. 

15 If required, a charge record for the session will be produced by the BSC in a similar way to those 
currently produced by BSC'S for telephone calls originated in the mobile network. The distant 
(source) end will normally be charged for sessions opened with an OPEN_SERVICE message 
as identified by the User's Internet name in the message, but if the mobile terminal behaves as 
a server it may wish to absorb or supplement the charge. A charge record may also be produced 

20 by the BSC's local router in order to charge the Mobile Network Provider for use of the Internet. 
All such details are administrative in nature and of no consequence to the present invention. 



5,e. 

The OPEN_SERVICE message also indicates the chosen protocol and the capacity required for 
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the virtual message path, but the information is not used until transferred to OPENJDONE 

messages returned to the mobile terminal and to the user by the source router. OPENJDONE 

messages indicate the chosen protocol to the user and inform the end setting up the virtual 

message path (in this case the mobile terminal) that the message path is complete. They also 

5 indicate to all routers along the message path the network capacity to be reserved and the 

message switching priority required for the virtual message path. 

6.a. Mobile terminal moves to new BSC area. 

Mobile transfer and "seamless" hand-over will now be described with reference to Figures 3A 
10 and 3B. When a mobile terminal migrates from one BSC area to another in mid-session, the first 
BSC sends via the Internet a MOB_TR AN SFER_REQUEST message to the new BSC (see 
Figure 3A). For this purpose each BSC will need to know the Internet addresses of its adjacent 
BSCs. The message identifies the mobile terminal, and repeats the source router address and 
session -record number taken from the OPEN_SERVICE message. 

15 

6.b. 

The new BSC prepares to receive messages from the mobile terminal via the new aerial tower 
but provides a buffer to store any messages destined for the mobile terminal that may be received 
from the user prior to completion of the handover. It then uses an OPENJVIOB JTRANSFER 
20 message with the address and record number from the MOB JTRANSFER_REQUEST message, 
to open a virtual message-path through the Internet and pick-up the virtual message-path to the 
user. The word MOB in the title of the OPEN_MOBJTRANSFER message indicates that a 
"seamless" transfer is required, i.e. changing the virtual message-path being used by the session 
without disturbing the session. 
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Thus, the new BSC arranges that, when messages are received from the mobile terminal via the 

new aerial tower they will be sent to the user; and that messages received from the user will be 
put into a buffer at the new BSC (to be forwarded to the mobile when it has changed to the new 
aerial tower). 

5 

6.c. 

The OPEN_MOB_TRANSFER message is treated as an ordinary OPEN message by all routers 
except the source router which uses the session -record number to identify the session and 
amends its switching tables to use the new virtual message-path. However, the source router 
10 continues to pass to the user any messages received from the mobile on the old virtual message- 
path. 

Thus, on receipt of the OPEN_MOB_TRANSFER message the source router arranges that 
messages received from the mobile on either the old or the new virtual message-path will be 
passed to the user; messages from the user to the mobile will be sent on the new channel only. 

15 

6.d. 

Completion of the handover will now be described with reference to Figure 3B. The next step 
following receipt of the OPEN_MOB_TRANSFER message is for the source router to return an 
OPEN_DONE message via the new virtual message-path to the new BSC and send a 
20 CLOSE_REQUEST message via the old virtual message-path to the old BSC. The 
OPEN_DONE message repeats the capacity and priority requirements from the old virtual 
message-path (the "chosen protocol" field is not used). 

6.e. 
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Upon receiving the OPEN_DONE message, the new BSC sends a REQUEST JDONE message 

to the old BSC which closes the virtual message-path created by the 

MOB_TRANSFER_REQUEST message. 

5 6.f 

The CLOSEJREQUEST message indicates that the source router has begun to use the new 
message path. By the time it is received at the old BSC, any user-to-mobile messages in the 
pipeline via the old message path will have cleared. Upon receiving the message, the old BSC 
instructs the mobile to change to the new aerial tower (i.e. to start communicating via the new 

10 BSC). When it detects that the mobile has changed, the old BSC sends a CLOSE message to the 
source router on the old virtual message-path. The CLOSE message indicates that the old BSC 
has ceased to use the old message path and by the time it reaches the source router, any mobile- 
to-user messages in the pipeline via the old virtual message-path will have cleared. When 
received, the source router amends its switching table to cease passing messages received from 

15 the old virtual message-path to the user. When the new BSC detects that the mobile has 
transferred to the new aerial tower it sends the contents of its storage buffer to the mobile 
terminal and, when empty, amends its switching table to send future messages directly to the 
mobile terminal. 

20 SESSIONS ORIGINATED BY MOBTT F TERMINALS 

The previous section showed how a mobile terminal can be accommodated at the destination end 
of an internet session. Further preferred embodiments of the present invention will now be 
described with reference to Figures 4, 5 and 5A according to which an Internet session can be 
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originated by a mobile terminal. According to this embodiment, a similar procedure may be used 

to that described above with reference to a session originated by a fixed tenninal. 



7.a. Mobile Terminal to Fixed Terminal 
5 Operation of a mobile terminal in originating an ordinary session (i.e. not to a special-service or 
another mobile tenninal) will now be described with reference to Figure 4. 



A mobile terminal originates a session by sending an OPEN&REFREQ message to its BSC (the 
"source" BSC) containing the address of the destination end and listing the available protocols. 
10 Inclusion of the term "REFREQ" in the message title indicates that the destination router should 
return its address and session record number to the originating BSC. 



7.b. 

Before forwarding the OPEN&REFREQ message to the source router (i.e. the source BSCs 
15 Internet access point) the source BSC adds to the message its own internet address, its session 
record number and the internet name of the mobile terminal (mobile terminals cannot provide 
their own name for security reasons). This information will be used by the BSCs local router if 
the distant end address is a special-service or another mobile tenninal. 



20 7.c. 

If the distant destination address is not a special-service or mobile terminal, the 
OPEN&REFREQ message is treated as an ordinary OPEN message by all routers except the 
destination router, i.e. the destination terminal's Internet access point. The destination router 
returns an OPEN_ACK message to the source BSC containing its internet address and session 
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record number before completing the virtual message-path to the addressed destination terminal 

which returns the OPEN_DONE message. 
7.d. 

5 On receipt of the OPEN_ACK message, the source BSC stores the destination router address and 
session record number. The OPEN_ACK message also indicates that there may be a delay before 
the OPEN_DONE message can be sent. e.g. when the addressed destination terminal requires use 
of a wake-up procedure. 

10 A BSC will produce charge records for all sessions where a mobile terminal connected via the 
BSC acts as the source unless a SERVICE_ACK message is passed via the BSC to the mobile 
terminal indicating that the distant end will produce the charge-record. The BSC will send charge 
invoices to the mobile network HQ which will charge the mobile terminal. 

15 Source mobile terminal migrates to new BSC - nFixari distant end) 

If in moving from one aerial tower to another during the session the source mobile terminal 
migrates to a new BSC area, the old BSC sends a MOB_TRANSFER_REQUEST message via 
the internet to the new BSC. The message identifies the migrating mobile terminal and provides 
20 the internet address and session -record number of the distant destination router from the 
OPEN_ACK message. A "seamless" handover follows, as described above with reference to 
Figures 3A and 3B bearing in mind that the mobile terminal is now at the source end and the 
fixed terminal at the destination end. 



19 

9.a. Mobile to Mobile or Mobile to Special-Service Session 
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A further preferred embodiment of the present invention will now be described with reference 
to Figures 5 and 5A according to which an Internet session can be set up between mobile 
5 terminals or from a mobile terminal to a special-service terminal. 

9.b. 

With reference to Figures 5 and 5A, when the source is a mobile terminal and the destination 
address in the OPEN&REFREQ message identifies a special-service or a mobile terminal, the 
10 source router returns a SERVICE_ACK message to the source mobile terminal via the BSC. 

The source BSC will have been expecting to receive references in an OPEN_ACK message. The 
receipt of a SERVICE_ACK message will inform the source BSC that the destination end is a 
server or BSC that will require new source-end references if the source mobile terminal migrates. 
15 The references requested from the destination end will be provided in the OPEN_SVCE&REF 
message as described below. The message also identifies that the charge record will be prepared 
at the distant end. 

9.c. 

20 The source router also sends a SVCE&REFJREQUEST message to a sorter to invoke service 
delivery and indicate that the source end is a mobile terminal and that its BSC requires references 
(i.e. the address and session -record number of the server or terminating BSC). The sorter re- 
addresses the message directly to the required server - or via the Mobile Location Service and 
currently active BSC to the required mobile terminal. The internet name, internet address and 
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session record number in the SVCE&REF_REQUEST message will be that provided by the 

source BSC in the original OPEN&REFREQ message. 
9.d. 

5 The destination special-services server or mobile terminal will use an OPEN_SVCE&REF 
message containing the user's internet name and the source BSC address and session -record 
number provided in the S VCE&REF_REQUEST message to open a virtual message-path via the 
Internet to the source BSC which will verify the internet name and use the session record number 
to pick-up the virtual message-path to the originating mobile terminal. 

10 The BSC will close the channel used by the BSC to forward the original 
OPEN&REFJREQUEST message to its local router. 

9.e. 

A server will include its own address and session -record number in an OPEN_SVCE&REF 
15 message. A destination BSC will add its address and session -record number to the message 
(generated by the mobile terminal) and will copy the source BSC address and record number 
from the message into its session -record for use if the destination mobile terminal migrates to 
another BSC. The source BSC will store the destination references provided in the message for 
use if the source mobile terminal migrates to another BSC. 

20 

9.f 

Hence both ends have references (distant-end address and session -record number) enabling them 
to transfer or handover the session as and when required. 
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lO.a. Service Transfer - with mobile terminal at distant end 

If a server needs to transfer a user to another server, where the user is a mobile terminal, the 
server will initiate service transfer by sending a TFR&REF_REQUEST message to a new server 
containing the same information as a TRANSFER_REQUEST message but the inclusion of the 

5 term "&REF" indicating that the distant end will require the new server's address and session 
-record number. The new server will use an OPEN_TFR&REF message to create a message-path 
to the source BSC and pick-up the message-path to the mobile terminal. The message contains 
the same information as an OPENJTCANSFER message but includes the new server's address 
and session -record number. The BSC will return OPEN_DONE to the new server and will send 

10 a CLOSE_REQUEST message on the old message path as previously described. It will also 
replace the old server's references obtained from the OPEN_SVCE&REF message with the new 
server's references provided in the OPENJITR&REF message. 

ll.a. Mobile terminal migrates to another BSC area - server or mobile terminal at distant end. 

15 MOB_TFR&REF_REQUEST messages will be used by BSCs to initiate handover to another 
BSC when the distant end is a server or another mobile terminal. The message contains the same 
information as a MOB_TRANSFER_REQUEST message but the inclusion of the term "&REF' 
indicates that the distant end will require the new BSCs address and session -record number. 
MOB_TRF&REF_REQUEST messages will also indicate which end produces the charge-record 

20 (if any) because the new BSC will not know whether it is at the source or destination end of the 
session. 

ll.b. 

The new BSC will use an OPEN_MOB_TFR&REF message containing the same information 
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as an OPEN_MOB_TRANSFER message to create a virtual message path to the distant server 

or BSC and pick-up the session in the seamless manner previously described. The 

OPEN_MOBJTFR&REF message will include the new BSC's address and session -record 

number. At the distant end, the server or BSC will replace its previously stored references with 

5 those contained in the message. 

ll.c. 

OPEN_MOB TFR&REF messages will indicate which end produces the charge record (if any) 
in order that source, destination and Gateway routers can produce the necessary charge records. 
10 Here a Gateway router is a router that has links to another provider's network and may be 
required to produce charge records for inter-provider accounting. 

12. 

The original S VCE&REFJREQUEST message (Figs. 5 & 5 A) informed the destination server 
15 or mobile terminal that the source requires references and the use of OPENJSVCE&REF by the 
destination mobile terminal conveyed the requirement to the destination BSC. The receipt of an 
OPEN_SVCE&REF message during the initial set-up informs a source BSC that the destination 
end requires references. Thereafter the need to provide references is perpetuated by the use of 
"&REF* in REQUEST message titles. 

20 

13.a.,13.b. 

According to a further embodiment of the present invention the message exchange between the 
BSC and the MLS includes the internet name of any mobile terminal that has Internet access. 
This requires that the MLS is aware of the Internet names of such mobile terminals. The 
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message exchange reporting to the MLS could advantageously take place over the Internet as an 



alternative to using the overlaying mobile network. 

The present invention has been described by way of example with reference to the Internet 
however, the scope of the invention is not limited to application to the Internet but is applicable 
to all internet protocol communications systems. 



CONTROL MESSAGES 



10 This section lists the format of the control messages employed in the Enhanced Internet including 
those required for communications involving mobile terminals. Each of the following messages 
is preceded, in use, by a Link Header Message identifying the virtual channel number (VCN) to 
which the message relates, e.g. 



Start 

VCN 0000 (control message channel) 
Total message length 
Allocated VCN 
Control message (as follows) 
Stop 

Suitable formats for the control messages referred to above are as follows: 
OPEN message 

25 

IP version 
Message length 
Function - OPEN 
Distant_host_address 
30 Port(l) 

Available protocols(2) 
Checksum 

OPEN&REFREO message 

35 



15 



20 



(1) Derived from protocol indicator 
specified by User. 

(2) Lists the protocols available for 
service delivery. The number of 

protocols may be deduced from the 
length field or from a "more" flag 



10 



24 

(used by mobiles to request references from terminating end) 
IP version 
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Message length 

Function - OPEN&REFREQ 

Distant_host_address 

Port 

Available protocols 
Orig. BSC's address(l) 
BSC's session record(l) 
User's Internet name(l) 
Checksum 



(1) The originating BSC adds its address, 
record no. and the User's Internet name 
to all OPEN&REFREQ messages for use 
in a SVCE&REF_REQUEST message if 
the distant host is a special-service or 
another mobile terminal. 



OPEN ACKmessage.(bef ore delayed OPEN DONE) 



15 



20 



IP version 
Message length 
Function -OPEN_ACK 
Dest-router address(l) 
Session_record no.(l) 
Checksum 



(1) The basic ACK message contains no 
parameters. When used in response to an 
OPEN&REFREQ message it holds the 
destination router's address and session 
record number. 



OPEN DONE message 

IP version 
25 Message length 

Function - OPEN_DONE 

Chosen protocol 

Forward capacity & priority 

Backward capacity & priority 
30 Checksum 



CLOSE REQUEST message 

35 IP version 

Message length 

Function - CLOSE_REQUEST (No parameters) 
Checksum 



40 CLOSE message 



45 



IP version 
Message length 

Function - CLOSE (No parameters) 
Checksum 



CLOSE ACK message, (per link - not end-to-end) 



25 

IP version 
Message length 

Function - CLOSE_ACK (No parameters) 
Checksum 
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SERVICE ACK message, (generated by router) 



10 



IP version 

Message length 

Function - SERVICE_ACK 

Checksum 



No parameters. Informs the User that the 
distant destination end is a "special-service" 
and that the transport-layer activity will be 
controlled by the distant destination end. 



SERVICE REQUEST message (generated bv router) 



15 



20 



25 



IP version 
Message length 

Function - SERVICEJREQUEST 
Sorter/server address(l) 
Distant_host_address(2) 
Source router address(3) 
Session record no.(3) 
User's Internet name(3) 
Available protocols(2) 
Checksum 



(1) the message is first addressed 
to a SORTER which re-addresses 
it to the service indicated by the 
Distant_host_address (via Mob. Loc. 
Svce. and current BSC if host is a 
mobile terminal.) 

(2) taken from the OPEN message 

(3) provided by source router 



SVCE&REF REQUEST message (generated bv routert 



30 



35 



40 



IP version 
Message length 

Function - SVCE&REF JREQUEST 
Sorter/server address(l) 
Distant_host_address(2) 
Source BSC address(2) 
Session record no,(2) 
User's Internet name(2) 
Available protocols(2) 
Checksum 

REQUEST DONE message 



(1) the message is first addressed 
to a SORTER which re-addresses 
it to the service indicated by the 
Distant_host_address. (via Mob. Loc. 
Svce. and current BSC if mobile 
terminal.) 

(2) taken from OPEN&REFREQ message 



45 



IP version 

Message length 

Function - REQUESTJDONE 

Checksum 



(No parameters) 



26 
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OPEN SERVICE message (generated by server or destination mobile) 



10 



IP version 

Message length 

Function - OPEN_SERVICE 

Source router address(l) 

Session record no.(l) 

User's Internet name(l) 

Chosen protocol(2) 

Forward capacity & priority(2) 

Backward capacity & priority(2) 

Checksum 



(1) From SERVICE_REQUEST 
message 



(2) Not used until transferred 
to OPEN_DONE message. (May 
be overridden by OPEN_OLD) 



15 



OPEN SVCE&REF message (generated by server or destination mobile) 



20 



25 



IP version 
Message length 

Function - OPEN_SVCE&REF 
Source BSC address(l) 
Session record no.(l) 
User's Internet name(l) 
Chosen protocol(2) 
Forward capacity & priority(2) 
Backward capacity & priority(2) 
Dest. BSC/server address(3) 
Dest. BSC/server record no.(3) 
Checksum 



(1) From SVCE&REFJREQUEST 
message 

(2) Not used until transferred to 
OPEN_DONE message. (May 
be overridden by OPENJDLD) 

(3) BSCs add their address and 
and session -record no. to all 
OPEN_SVCE&REF messages 
from their mobile terminals 



30 



TRANSFER REQUEST or ADD REQUEST message, (generated by server) 



35 



40 



IP version 
Message length 

Function - TRANSFER/ADD_REQ 
Sorter/New server address (1) 
Source, router address(2) 
router's record no. (2) 
User's Internet name(2) 
Available protocols(2) 
Misc. - variable length(3) 
Checksum. 



(1) If addressed to a Sorter, a "Distant-host- 
address" will be put into the Misc. field. 



(2) From SERVICE_REQUEST or from 
previous TRANSFER/ ADD JREQUEST 
message 

(3) server - server inf. 



45 



TFR&REF or ADD&REF REQUEST message (generated by server) 



IP version 
Message length 



(1) If addressed to a Sorter, a "Distant-host- 
address" will be put into the Misc. field. 



Function - TFR&REF/ ADD&REFJIEQ. 
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Sorter/New server address (1) 
Source address(2) 
BSCs record no.(2) 
User's Internet name(2) 
Available protocols(2) 
Misc. - variable length(3) 
Checksum. 



(2) From S VCE&REF_REQUEST or from 
previous TFR&REF/ADD&REF_REQ 
message 

(3) server - server inf 



10 MOB TRANSFER REQUEST message (generated by BSC - fixed distant end) 

IP version 
Message length. 

Function - MOB_TRANSFER_REQ . 
15 New BSC address 

Distant router address(l) (1) From SERVICEJREQUEST message, 

router's record no.(l) OPEN_ACK message or previous 

Mobile terminal identity. MOB JTRANSFERJREQUEST 

message 

20 Checksum. 

MOB TFR&REF REQUEST message (generated by BSC - server or mobile distant end) 



25 



30 



35 



40 



IP version. 
Message length. 

Function - MOB_TFR&REF_REQ. 

New BSC address 

Distant server/BSC address (1) 

server/BSC record no.(l) 

Mobile terminal identity. 

Charge-record flag 

Checksum. 



(1) From SVCE&REF_REQUEST message, 
OPENJSVCE&REF message or 
previous MOB_TFR&REF_REQ 



OPEN TRANSFER or OPEN ADD message (generated bv server) 

Same as OPENJSERVICE message apart from name in Function field which indicates 
TRANSFER or ADD action required. 

OPEN TFR&REF or OPEN ADD&REF message (generated bv server) 

Same as OPENJSVCE&REF message apart from name in Function field which indicates 
TRANSFER or ADD action required . 



45 OPEN MOB TRANSFER message (migrating mobile - fixed distant end) 



IP version 
Message length 



5 
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Function - OPEN_MOB_TFR 

Distant router address(l) (1) From MOBJTFR_REQUEST message. 

Session record no.(l) 

Checksum 

OPEN MOB TFR&KKF message (migrating mobile - server or mobile distant end) 



IP version 

Message length (1 ) From MOBJTFR&REFJREQUEST 

10 Function - OPENJMOBJTFR&REF message 

server/Distant BSC address(l) 

Session record no.(l) (2) BSCs add their address 

New BSC address(2) and session -record no. 

New BSC record no.(2) 
1 5 Charge-record flag 

Checksum 

FAILURE message 

20 IP version 

Message length 

Function - FAILURE 

(As required) [what is as required?] 

Checksum 

25 

Typical failure messages - (might merely be fault numbers) 
Destination address not recognised / protected; 
Destination terminal out-of-service / not responding; 
Destination terminal location unknown (off-line mobile); 
30 Unable to commit sufficient capacity; 

Congestion (unable to commit any capacity) / network failure; 
Internet name check fail. 
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CLAIMS 

1 . A communications protocol for providing a connection-oriented interconnection via an 
internet protocol communications system between a first mobile terminal and a node, in 
which the first mobile terminal and the node form part of an internet session; in which 
the first mobile terminal is initially connected to the node via a first mobile controller 
(MC) in which the protocol comprises means for providing to the first MC an internet 
address relating to the node and a record number identifying the internet session. 

2. The communications protocol as claimed in claim 1 in which the node comprises a fixed 
terminal, in which the fixed terminal is connected to the internet protocol 
communications system via a router; 

in which the internet address identifies the router, and in which the record number is 
allocated by the router. 

3. The communications protocol as claimed in claim 1 in which the node comprises a server, 
in which the internet address identifies the server, and in which the record number is 
allocated by the server. 

4. The communications protocol as claimed in claim 1 in which the node comprises a further 
mobile terminal, in which the further mobile terminal is connected to the internet 
protocol communications system via a further MC; 

in which the internet address identifies the further MC, and in which the record number 
is allocated by the further MC. 



30 
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The communications protocol as claimed in any above claim including the step of 
maintaining the session as the interconnection between the first mobile terminal and the 
node is redirected from via the first MC to via a second MC. 

The protocol as claimed in claim 5 in which the first MC sends a message via the internet 
protocol communications system to the second MC for requesting the redirection. 

The communications protocol as claimed in any one of claims 5 and 6 including the steps 
of establishing the interconnection as a first virtual message-path (VMP) between the first 
mobile terminal and the node; and for transferring the interconnection from the first VMP 
to a second VMP in which the first MC is included in the first VMP and the second MC 
is included in the second VMP. 

The protocol as claimed in any one of claims 5 to 7 as dependent from any one 
of claims 2 to 4 in which the second MC opens the second VMP to the server or 
to the node's router or to the further MC. 

The protocol as claimed in claim 8 including the step of extending the second VMP from 
the node's router to the node via that part of the first VMP that extends between the 
node's router and the node. 

The protocol as claimed in claim 8 including the step of extending the second VMP from 
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the further MC to the further mobile terminal via that part of the first VMP that extends 



between the further MC and the further mobile terminal. 

11. The protocol as claimed in any one of claims 5 to 10 in which the second MC instructs 
the server or the node's router or the further MC to redirect the interconnection from via 
the first MC to via the second MC. 

12. The communications protocol as claimed in any one of claims 5 to 1 1 in which redirection 

of the interconnection takes place in a seamless manner. 

13. The communications protocol as claimed in any one of claims 5 tol2 including, during 
redirection of the interconnection, the steps of the node's router accepting messages from 
the second MC in addition to the first MC for forwarding to the node and at the same 
time forwarding all messages received from the node for forwarding to the first mobile 
terminal via the second MC. 

14. The communications protocol as claimed in any above claim in which the internet 

session is initiated by the node; and in which communication between the first mobile 
terminal and the node takes place over a VMP set up by the first mobile terminal. 

15. The communications protocol as claimed in any one of claims 1 to 13 in which the 
internet session is initiated by the first mobile terminal; 

and in which communication between the first mobile terminal and the node takes place 
over a VMP set up by the first mobile terminal. 
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A communications protocol for interconnecting a first mobile terminal via the internet 
protocol communications system with another fixed or mobile terminal, in which the first 
mobile terminal is treated as a special service. 

A communications protocol substantially as described with reference to and as illustrated 
in Figures 3, 3A, 3B, 4, 5, 5A and 6 of the drawings. 

A communications system comprising means for implementing the protocol of any above 
claim. 
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